Плюсы

В ОЗУ
Для поисковых операций

Минусы

много ОЗУ
Обновление индексов затратно
Вставка данных дольше

Когда нужно?

Чтение чаще, чем обновление
На те поля, что участвуют в поиске
Эксперименты показывают что производ улучшилась
Неизбежны на уникальных полях
На дочерних ключах FK

составные индексы на те поля по которым часто будет поиска (на 2 атрибута БД)

на состовном хорошо ищет и по 1му

IDX_nameAtribute

Когда не нужно?

маленткая таблица
часто выполняются INSERT, UPDATE
столбец содержит много null
столбцы которые часто обновляются

Типы Индексов

их куча и они математически сложные

Кластаризованные - используют PK - он не требует явного объявления и создаётся по умолчанию при определении ключа - оттсортирован по умолчанию

Некластеризированные - индексы к неключевым столбцам - хранится в отдельном месте - медленнее класторизованного тк есть доп шаг перехода по ссылке в основную таблицу

Двоичный поиск - эффективный алгоритм поиска записи в сортированном списке

Деление данных пополам - поиска далее в какой половине есть

для 8 найдёт максимум за 3

для 10000 за 14

для 1 000 000 за 20

log2(n)

По кол ву полей простые или составные

Уникальные и не уникальные

Первичные (уникальные), кластерные (может дублирование), не кластерные (большинство) может быть токо 1 кластенрный в табл

Партиционирование по индексам

Разряженные(диапозон) или плотные(большинство, каждую запись)

одноуровненые, многоуровневые(деревья)

покрывающие или непокрывающие (зависит от запроса) при той же таблице

B-tree сбалансирование (для запросов < или >, иди направо или налево)

T-tree всегда всё дерево в ОЗУ

R-tree (МП, поиск заправки, такси рядом)

Hash-table (идеально для поиска равенства, но < или > оч плохо)

индексы весят = бд

лучше пересоздавать раз в год

Действие

БД анализирует все возможные пути запроса, выбирая самый оптимальный

План выполнения запроса - возможный путь - последовательность операций для получения результата SQL запроса СУРБД (Реляционная СУБД)

Оптимизатор запросов - компонент СУРБД определяющий самый эффективный план запроса

Если в запросе есть поле под индексом - БД начнёт поиск с него

Можно делать индексы по несколькоим колонкам

Синтаксис

DROP INDEX index_name;

Структуры хранения (коротко)

B-деревья: хорошие для диапазонных запросов и смешанных чтение/запись; вставки раскидывают страницы.
LSM-деревья: быстрая запись (append + слияния), чтения могут трогать несколько уровней; требуют компакции и больших кешей.
Выбор: LSM для write-heavy и больших объёмов, B-дерево для OLTP/диапазонов.

Последнее обновление 4 месяца назад